User attestation and authentication conventionally requires inputting user credentials via an operating system (OS) and/or software (i.e., via in-band communications). For example, to log into a service provider's (SP) cloud-based email service the user must enter a username and password via an OS and browser. Reliance on such passwords, however, may be insufficient for maintaining secure computing practices.
For example, entry of password information via in-band communications with an OS or software module leaves the system exposed to security threats (e.g., key loggers, man-in-the-middle attacks). Even strong passwords, such as hardware or software One Time Passwords (OTP) which are theoretically supposed to verify the user access request actually originates from a physical person, are problematic due to the in-band nature of how the password is communicated (i.e., such a password is still susceptible to key loggers and the like). Furthermore, even if such passwords are not intercepted, these same passwords are weak because Trojans, viruses, and worms may pose as a physical person and spread across multiple endpoints. As yet another problem with most passwords, humans typically cannot recall unique, long, otherwise strong passwords for every internet service they subscribe to. As a result, to reduce the burden of recall many users reuse the same password across multiple sites. Even if users use several different passwords, such passwords are often short, predictable and otherwise weak and equally ineffective as the above options.
To increase the strength of passwords, identity management services implement multi-factor authentication (MFA) which includes, for example, retinal scanning, fingerprint scanning, and the like. Such credentials are unique, do not need to be memorized by a user, and are generally considered strong for passwords. However, the actual real world implementation of such credentials can be problematic when viewed in a realistic setting where, for example, a user wants to interact with multiple service providers.
Specifically, identity management services implement MFA by testing corresponding MFA policies on the server—not on the client. Thus, proof of user presence is established externally to the platform (e.g., by hardware token on the client-side and/or by forwarding authentication minutia to the server). This may be because the platform itself may not have attestation capability or, if it does the trusted path mechanism (e.g., Trusted Platform Module (TPM)) may be external to the attestation capability.
Consequently, because the status of the user's authentication is held by the server (and not on the client), if a different service provider (on a different server) wants to know the authentication status of the user there are two options. First, the user may have to re-authenticate by, for example, again submitting a retinal scan. This can be burdensome to a user, especially when implemented with MFA credentials (e.g., taking multiple retinal scans). Second, the two servers must federate the user's identity and implement backend protocols to track the user's authentication status. This approach has privacy implications that the user is not able to directly control, which again decreases security. Neither option is optimal.